Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / standards / CCITT / 1992 / X / x25_4.asc < prev next >

Wrap

Text File | 1993-07-15 | 85.4 KB | 3,767 lines

5.2.4 Clear request and clear indication packets Figure 8/X.25 illustrates the format of clear request and clear indication packets, in basic and extended formats. Bits 8 7 6 5 4 3 2 1 Octet s 1 General format identifier (see Note) Logical channel group number 2 Logical channel number 3 Packet type identifier 0 0 0 1 0 PAGE70 Fascicle VIII.8 - X.25 0 1 1 4 Clearing cause 5 Diagnostic code a) 4 Address block b) (see S 5.2.1) Facility length b) Facilites b) Clear user data b) a) This field is not mandatory in the basic format of clear request packets (see S 5.2.4.1). b) Used only in the extended format (see S 5.2.4.2). Note - Coded X001 (modulo 8) or X010 (modulo 128). FIGURE 8/X.25 Clear request and clear indication packet format 5.2.4.1 Basic format 5.2.4.1.1 Clearing cause field Octet 4 is the clearing cause field and contains the reason for the clearing of the call. In the clear request packets, the clearing cause field should be set by the DTE to one of the following values: bits: 8 7 6 5 4 3 2 1 value: 0 0 0 0 0 0 0 0 or: 1 X X X X X X X where each X may be independently set to 0 or 1 by the DTE. Fascicle VIII.2 - Rec. X.25 PAGE93 The DCE will prevent values of the clearing cause field other than those shown above from reaching the other end of the call by either accepting the clear request packet and forcing the clearing cause field to all zeros in the corresponding clear indication packet, or considering the clear request as an error and following the procedure described in Annex C. The coding of the clearing cause field in clear indication packets is given in Table 20/X.25. TABLE 20/X.25 Coding of clearing cause field in clear indication packet Bits 8 7 6 5 4 3 2 1 DTE originated 0 0 0 0 0 0 0 0 DTE originated a) 1 X X X X X X X Number busy 0 PAGE70 Fascicle VIII.8 - X.25 0 0 0 0 0 0 1 Out of order 0 0 0 0 1 0 0 1 Remote procedure error 0 0 0 1 0 0 0 1 Reverse charging acceptance not 0 0 0 1 1 0 0 subscribed b) Fascicle VIII.2 - Rec. X.25 PAGE93 1 Incompatible destination 0 0 1 0 0 0 0 1 Fast select acceptance not 0 0 1 0 1 0 0 1 subscribed b) Ship absent c) 0 0 1 1 1 0 0 1 Invalid facility request 0 0 0 0 PAGE70 Fascicle VIII.8 - X.25 0 0 1 1 Acces barred 0 0 0 0 1 0 1 1 Local procedure error 0 0 0 1 0 0 1 1 Network congestion 0 0 0 0 0 1 0 1 Not obtainable 0 Fascicle VIII.2 - Rec. X.25 PAGE93 0 0 0 1 1 0 1 RPOA out of order b) 0 0 0 1 0 1 0 1 a) When bit 8 is set to 1, the bits represented by Xs are those included by the remote DTE in the clearing or restarting cause field of the clear or restart request packet respectively. b) May be received only if the corresponding optional user facility is used. c) Used in the conjunction with mobile maritime service. PAGE70 Fascicle VIII.8 - X.25 5.2.4.1.2 Diagnostic code Octet 5 is the diagnostic code and contains additional information on the reason for the clearing of the call. In a clear request packet, the diagnostic code is not mandatory. In a clear indication packet, if the clearing cause field indicates "DTE originated", the diagnostic code is passed unchanged from the clearing DTE. If the clearing DTE has not provided a diagnostic code in its clear request packet, then the bits of the diagnostic code in the resulting clear indication packet will all be zero. When a clear indication packet results from a restart request packet, the value of the diagnostic code will be that specified in the restart request packet, or all zeros in the case where no diagnostic code has been specified in the restart request packet. When the clearing cause field does not indicate "DTE originated", the diagnostic code in a clear indication packet is network generated. Annex E lists the codings for network generated diagnostics. The bits of the diagnostic code are all set to 0 when no specific additional information for the clearing is supplied. Note - The contents of the diagnostic code field do not alter the meaning of the cause field. A DTE is not required to undertake any action on the contents of the diagnostic code field. Unspecified code combinations in the diagnostic code field shall not cause the DTE to refuse the cause field. 5.2.4.2 Extended format The extended format is used for clear request and clear indication packets only when the DTE or the DCE need to use the called and/or calling DTE address fields, the facility field and/or the clear user data field in conjunction with one or several optional user facilities described in SS 6 and 7. The called DTE address field is used only when the called line address modified notification facility is used in clearing, in response to an incoming call or call request packet. When the extended format is used, the diagnostic code field, the DTE address length fields and the facility length field must be present. Optionally, the clear user data field may also be present. 5.2.4.2.1 Address block The address block is described in S 5.2.1. 5.2.4.2.2 Facility length field The octet following the address block indicates the length of the facility field, in octets. The facility length indicator is binary coded and bit 1 is the low order bit of the indicator. 5.2.4.2.3 Facility field The facility field is present in the clear request or the clear indication packet only in conjunction with one or several optional user facilities requiring some indication in this packet. The coding of the facility field is defined in SS 6 and 7. The facility field contains an integral number of octets. The actual maximum length of this field depends on the facilities which are offered by the network. However, this maximum does not exceed 109 octets. Note - It is for further study whether another value should be defined, relative to the total number of octets in the packet. 5.2.4.2.4 Clear user data field This field may be present only in conjunction with the fast select facility (see S 6.16) or the call deflection selection facility (see S 6.25.2.2). It has a maximum length of 128 octets in the first case, of 16 or 128 octets in the second case: whether the maximum length is 16 or 128 octets when using the call deflection selection facility is specified in S 6.25.2.2. Note 1 - Some networks require the clear user data field to contain an integral number of octets (see the note in S 3). Note 2 - The network does not act on any part of the clear user data field. See Recommendation X.244. 5.2.5 DTE and DCE clear confirmation packets Figure 9/X.25 illustrates the format of the DTE and DCE clear confirmation packets, in the basic or extended format. Bits 8 7 6 5 4 3 2 1 Octet s 1 General format identifier (see Note) Logical channel group number 2 Logical channel number 3 Fascicle VIII.2 - Rec. X.25 PAGE93 Packet type identifier 0 0 0 1 0 1 1 1 4 Address block a) (see S 5.2.1) Facility length a) Facilities a) a) Used only in the extended format of DCE clear confirmation packets. Note - Coded X001 (modulo 8) or X010 (modulo 128). FIGURE 9/X.25 DTE and DCE clear confirmation packet format The extended format may be used for DCE clear confirmation packets only in conjunction with the charging information facility described in S 6.22. It is not used for DTE clear confirmation packet. 5.2.5.1 Address block The address block is described in S 5.2.1. The calling and called DTE address length fields are coded with all zeros and the called and calling DTE address fields are not present. 5.2.5.2 Facility length field The octet following the address block indicates the length of the facility field, in octets. The facility length indicator is binary coded and bit 1 is the low order bit of the indicator. 5.2.5.3 Facility field The coding of the facility field is defined in SS 6 and 7. The facility field contains an integral number of octets. The actual maximum length of this field depends on the facilities which are offered by the network. However, this maximum does not exceed 109 octets. Note - It is for further study whether another value should be defined, relative to the total number of octets in the packet. 5.3 Data and interrupt packets 5.3.1 DTE and DCE data packets Figure 10/X.25 illustrates the format of the DTE and DCE data packets. Bits 8 7 6 5 4 3 2 PAGE70 Fascicle VIII.8 - X.25 1 Octet s 1 General format identifier Logical channel group number Q D 0 1 2 Logical channel number 3 P(R) M P(S) 0 User data (Modulo 8) Fascicle VIII.2 - Rec. X.25 PAGE93 Bits 8 7 6 5 4 3 2 1 Octet s 1 General format identifier Logical channel group number Q D 1 0 2 Logical channel number PAGE70 Fascicle VIII.8 - X.25 3 P(S) 0 P(R) M 4 User data (When extended to modulo 128) D Delivery confirmation bit M More data bit Q Qualifier bit FIGURE 10/X.25 DTE and DCE data packet format Fascicle VIII.2 - Rec. X.25 PAGE93 5.3.1.1 Qualifier (Q) bit Bit 8 of octet 1 is the qualifier (Q) bit. 5.3.1.2 Delivery confirmation (D) bit Bit 7 of octet 1 is the delivery confirmation (D) bit. 5.3.1.3 Packet receive sequence number Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended, are used for indicating the packet receive sequence number P(R). P(R) is binary coded and bit 6, or bit 2 when extended, is the low order bit. 5.3.1.4 More Data bit Bit 5 in octet 3, or bit 1 in octet 4 when extended, is used for the More Data (M bit): 0 for no more data and 1 for more data. 5.3.1.5 Packet send sequence number Bits 4, 3 and 2 of octet 3, or bits 8 through 2 of octet 3 when extended, are used for indicating the packet send sequence number P(S). P(S) is binary coded and bit 2 is the low order bit. 5.3.1.6 User data field Bits following octet 3, or octet 4 when extended, contain user data. Note - Some networks require the user data field to contain an integral number of octets (see the note in S 3). 5.3.2 DTE and DCE interrupt packets Figure 11/X.25 illustrates the format of the DTE and DCE interrupt packets. Bits 8 7 6 5 4 3 2 1 Octet s 1 General format identifier (see Note) Logical channel group number 2 Logical channel number 3 PAGE70 Fascicle VIII.8 - X.25 Packet type identifier 0 0 1 0 0 0 1 1 4 Interrupt user data Note - Coded 0001 (modulo 8) or 0010 (modulo 128). FIGURE 11/X.25 DTE and DCE interrupt packet format Fascicle VIII.2 - Rec. X.25 PAGE93 5.3.2.1 Interrupt user data field Octet 4 and any following octets contain the interrupt user data. This field may contain from 1 to 32 octets. Note - Some networks require the interrupt user data field to contain an integral number of octets (see the note in S 3). 5.3.3 DTE and DCE interrupt confirmation packets Figure 12/X.25 illustrates the format of the DTE and DCE interrupt confirmation packets. Bits 8 7 6 5 4 3 2 1 Octet s 1 General format identifier (see Note) Logical channel group number 2 Logical channel number 3 Packet type identifier 0 0 1 PAGE70 Fascicle VIII.8 - X.25 0 0 1 1 1 Note - Coded 0001 (modulo 8) or 0010 (modulo 128). FIGURE 12/X.25 DTE and DCE interrupt confirmation packet format Fascicle VIII.2 - Rec. X.25 PAGE93 5.4 Flow control and reset packets 5.4.1 DTE and DCE receive ready (RR) packets Figure 13/X.25 illustrates the format of the DTE and DCE RR packets. Bits 8 7 6 5 4 3 2 1 Octet s 1 General format identifier Logical channel group number 0 0 0 1 PAGE70 Fascicle VIII.8 - X.25 2 Logical channel number 3 P(R) 0 0 0 0 1 (Modulo 8) Bits 8 7 6 5 4 3 2 1 Octet s 1 General format identifier Logical channel group number Fascicle VIII.2 - Rec. X.25 PAGE93 0 0 1 0 2 Logical channel number 3 Packet type identifier 0 0 0 0 0 0 0 1 4 P(R) 0 (When extended to modulo 128) FIGURE 13/X.25 DTE and DCE RR packet format PAGE70 Fascicle VIII.8 - X.25 5.4.1.1 Packet receive sequence number Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended, are used for indicating the packet receive sequence number P(R). P(R) is binary coded and bit 6, or bit 2 when extended, is the low order bit. 5.4.2 DTE and DCE receive not ready (RNR) packets Figure 14/X.25 illustrates the format of the DTE and DCE RNR packets. Bits 8 7 6 5 4 3 2 1 Octet s 1 General format identifier Logical channel group number 0 0 0 1 Fascicle VIII.2 - Rec. X.25 PAGE93 2 Logical channel number 3 P(R) 0 0 1 0 1 (Modulo 8) Bits 8 7 6 5 4 3 2 1 Octet s 1 General format identifier PAGE70 Fascicle VIII.8 - X.25 Logical channel group number 0 0 1 0 2 Logical channel number Packet type identifier 3 0 0 0 0 0 1 0 1 4 P(R) 0 (When extended to modulo 8) FIGURE 14/X.25 DTE and DCE RNR packet format Fascicle VIII.2 - Rec. X.25 PAGE93 5.4.2.1 Packet receive sequence number Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended, are used for indicating the packet receive sequence number P(R). P(R) is binary coded and bit 6, or bit 2 when extended, is the low order bit. 5.4.3 Reset request and reset indication packets Figure 15/X.25 illustrates the format of the reset request and reset indication packets. Bits 8 7 6 5 4 3 2 1 Octet s 1 General format identifier Logical channel group number 2 Logical channel number 3 Packet type identifier 0 0 0 PAGE70 Fascicle VIII.8 - X.25 1 1 0 1 1 4 Resetting cause 5 Diagnostic code a) a) This field is not mandatory in reset request packets. Note - Coded 0001 (modulo 8) or 0010 (modulo 128). FIGURE 15/X.25 Reset request and reset indication packet format 5.4.3.1 Resetting cause field Octet 4 is the resetting cause field and contains the reason for the reset. In reset request packets, the resetting cause field should be set by the DTE to one of the following values: bits: 8 7 6 5 4 3 2 1 value: 0 0 0 0 0 0 0 0 or: 1 X X X X X X X where each X may be independently set to 0 or 1 by the DTE. The DCE will prevent values of the resetting cause field, other than those shown above, from reaching the other end of the virtual call or permanent virtual circuit by either accepting the reset request packet and forcing the resetting cause field to all zeros in the corresponding reset indication packet, or considering the reset request as an error and following the procedure described in Annex C. The coding of the resetting cause field in a reset indication packet is given in Table 21/X.25. TABLE 21/X.25 Coding of resetting cause field in reset indication packet Bits 8 7 6 5 4 3 2 1 DTE originated 0 0 0 0 Fascicle VIII.2 - Rec. X.25 PAGE93 0 0 0 0 DTE originated a) 1 X X X X X X X Out or order b) 0 0 0 0 0 0 0 1 Remote procedure error 0 0 0 0 0 0 1 1 Local procedure error 0 PAGE70 Fascicle VIII.8 - X.25 0 0 0 0 1 0 1 Network congestion 0 0 0 0 0 1 1 1 Remote DTE operational b) 0 0 0 0 1 0 0 1 Network operational b) 0 0 0 0 1 1 1 Fascicle VIII.2 - Rec. X.25 PAGE93 1 Incompatible destination 0 0 0 1 0 0 0 1 Network out of order b) 0 0 0 1 1 1 0 1 a) When bit 8 is set to 1, the bits represented by Xs are those indicated by the remote DTE in the resetting cause field (virtual calls and permanent virtual circuits) or the restarting cause field (permanent virtual circuits only) of the reset or restart request packet, respectively. b) Applicable to permanent virtual circuits only. 5.4.3.2 Diagnostic code Octet 5 is the diagnostic code and contains additional information on the reason for the reset. In a reset request packet the diagnostic code is not mandatory. In a reset indication packet, if the resetting cause field indicates "DTE originated", the diagnostic code has been passed unchanged from the resetting DTE. If the DTE requesting a reset has not provided a diagnostic code in its reset request packet, then the bits of the diagnostic code in the resulting reset indication packet will all be zeros. When a reset indication packet results from a restart request packet, the value of the diagnostic code will be that specified in the restart request packet, or all zeros in the case where no diagnostic code has been specified in the restart request packet. When the resetting cause field does not indicate "DTE originated", the diagnostic code in a reset indication packet is network generated. Annex E lists the codings for network generated diagnostics. The bits of the diagnostic code are all set to 0 when no specific additional information for the reset is supplied. Note - The contents of the diagnostic code field do not alter the meaning of the cause field. A DTE is not required to undertake any action on the contents of the diagnostic code field. Unspecified code combinations in the diagnostic code field shall not cause the DTE to not accept the cause field. PAGE70 Fascicle VIII.8 - X.25 5.4.4 DTE and DCE reset confirmation packets Figure 16/X.25 illustrates the format of the DTE and DCE reset confirmation packets. Bits 8 7 6 5 4 3 2 1 Octets 1 General format identifier (see Logical channel group number Note) 2 Logical channel number 3 Packet type identifier 0 0 0 1 Fascicle VIII.2 - Rec. X.25 PAGE93 1 1 1 1 Note - Coded 0001 (modulo 8) or 0010 (modulo 128). FIGURE 16/X.25 DTE and DCE reste confirmation packet format 5.5 Restart packets 5.5.1 Restart request and restart indication packets Figure 17/X.25 illustrates the format of the restart request and restart indication packets. Bits 8 7 6 5 4 3 2 1 Octet s 1 General format identifier (see Note) 0 0 0 PAGE70 Fascicle VIII.8 - X.25 0 2 0 0 0 0 0 0 0 0 3 Packet type identifier 1 1 1 1 1 0 1 1 4 Restarting cause 5 Diagnostic code a) a) This field is not mandatory in restart request packets. Note - Coded 0001 (modulo 8) or 0010 (modulo 128). FIGURE 17/X.25 Restart request and restart indication packet format Fascicle VIII.2 - Rec. X.25 PAGE93 5.5.1.1 Restarting cause field Octet 4 is the restarting cause field and contains the reason for the restart. In restart request packets, the restarting cause field should be set by the DTE to one of the following values: bits: 8 7 6 5 4 3 2 1 value: 0 0 0 0 0 0 0 0 or: 1 X X X X X X X where each X may be independently set to 0 or 1 by the DTE. The DCE will prevent values of the restarting cause field, other than those shown above, from reaching the other end of the virtual calls and/or permanent virtual circuits by either accepting the restart request packet and forcing the clearing or resetting cause field to all zeros in the corresponding clear and/or reset indication packets, or considering the restart request as an error and following the procedure described in Annex C. The coding of the restarting cause field in the restart indication packets is given in Table 22/X.25. TABLE 22/X.25 Coding of restarting cause field in restart indication packet Bits 8 7 6 5 4 3 2 1 Local procedure error 0 0 0 0 0 0 0 1 Network congestion 0 0 0 0 0 PAGE70 Fascicle VIII.8 - X.25 0 1 1 Network operational 0 0 0 0 0 1 1 1 Registration/cancellation 0 1 1 1 1 1 1 1 confirmed a) a) May be received only if the optional on-line facility registration facility is used. 5.5.1.2 Diagnostic code Octet 5 is the diagnostic code and contains additional information on the reason for the restart. In a restart request packet, the diagnostic code is not mandatory. The diagnostic code, if specified, is passed to the corresponding DTEs as the diagnostic code of a reset indication packet for permanent virtual circuits or a clear indication packet for virtual calls. The coding of the diagnostic code field in a restart indication packet is given in Annex E. The bits of the diagnostic code are all set to zero when no specific additional information for the restart is supplied. Note - The contents of the diagnostic code field do not alter the meaning of the cause field. A DTE is not required to undertake any action on the contents of the diagnostic code field. Unspecified code combinations in the diagnostic code field shall not cause the DTE to not accept the cause field. Fascicle VIII.2 - Rec. X.25 PAGE93 5.5.2 DTE and DCE restart confirmation packets Figure 18/X.25 illustrates the format of the DTE and DCE restart confirmation packets. Bits 8 7 6 5 4 3 2 1 Octet s 1 General format identifier (see Note) 0 0 0 0 2 0 0 0 0 0 PAGE70 Fascicle VIII.8 - X.25 0 0 0 3 Packet type identifier 1 1 1 1 1 1 1 1 Note - Coded 0001 (modulo 8) or 0010 (modulo 128). FIGURE 18/X.25 DTE and DCE restart confirmation packet format 5.6 Diagnostic packet Figure 19/X.25 illustrates the format of the diagnostic packet. Bits 8 7 6 5 4 3 2 1 Octet s Fascicle VIII.2 - Rec. X.25 PAGE93 1 General format identifier (see Note 0 0 0 0 1) 2 0 0 0 0 0 0 0 0 3 Packet type identifier 1 1 1 1 0 0 0 1 4 Diagnostic code 5 Diagnostic explanation (see Note 2) PAGE70 Fascicle VIII.8 - X.25 Note 1 - Coded 0001 (modulo 8) or 0010 (modulo 128). Note 2 - The figure is drawn assuming the diagnostic explanation field is an integral number of octets in length. FIGURE 19/X.25 Diagnostic packet format Fascicle VIII.2 - Rec. X.25 PAGE93 5.6.1 Diagnostic code field Octet 4 is the diagnostic code and contains information on the error condition which resulted in the transmission of the diagnostic packet. The coding of the diagnostic code field is given in Annex E. 5.6.2 Diagnostic explanation field When the diagnostic packet is issued as a result of the reception of an erroneous packet from the DTE (see Tables C-1/X.25 and C-2/X.25), this field contains the first three octets of header information from the erroneous DTE packet. If the packet contains less than 3 octets, this field contains whatever bits were received. When the diagnostic packet is issued as a result of a DCE time-out (see Table D-1/X.25), the diagnostic explanation field contains 2 octets coded as follows: - bits 8, 7, 6 and 5 of the first octet contain the general format identifier for the interface; - bits 4 to 1 of the first octet and bits 8 to 1 of the second octet are all 0 for expiration of time-out T10 and give the number of the logical channel on which the time-out occurred for expiration of time-out T12 or T13. 5.7 Packets required for optional user facilities 5.7.1 DTE reject (REJ) packet for the packet retransmission facility Figure 20/X.25 illustrates the format of the DTE REJ packet, used in conjunction with the packet retransmission facility described in S 6.4. Bits 8 7 6 5 4 3 2 1 Octets 1 General format identifier Logical channel group number 0 0 0 PAGE70 Fascicle VIII.8 - X.25 1 2 Logical channel number 3 Packet type identifier P(R) 0 1 0 0 1 (Modulo 8) Bits 8 7 6 Fascicle VIII.2 - Rec. X.25 PAGE93 5 4 3 2 1 Octets 1 General format identifier Logical channel group number 0 0 1 0 2 Logical channel number 3 Packet type identifier 0 0 PAGE70 Fascicle VIII.8 - X.25 0 0 1 0 0 1 4 P(R) 0 (When extended to modulo 128) FIGURE 20/X.25 DTE REJ packet format Fascicle VIII.2 - Rec. X.25 PAGE93 5.7.1.1 Packet receive sequence number Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended, are used for indicating the packet receive sequence number P(R). P(R) is binary coded and bit 6, or bit 2 when extended, is the low order bit. 5.7.2 Registration packets for the on-li e facility registration facility 5.7.2.1 Registration request packet Figure 21/X.25 illustrates the format of the registrat e s t packet. Bits 8 7 6 5 4 3 2 1 Octets 1 General format identifier (see Note 1) 0 0 0 0 2 0 0 0 PAGE70 Fascicle VIII.8 - X.25 0 0 0 0 0 3 Packet type identifier 1 1 1 1 0 0 1 1 4 DTE address length DCE address length DCE and DTE address(es) (see Note 2) 0 0 0 0 0 Registration length Fascicle VIII.2 - Rec. X.25 PAGE93 Registration Note 1 - Coded 0001 (modulo 8) or 0010 (modulo 128). Note 2 - The figure is drawn assuming the total number of address digits present is odd. FIGURE 21/X.25 Registration request packet format 5.7.2.1.1 Address length fields Octet 4 consists of the field length indicators for the DTE and DCE addresses. Bits 4, 3, 2 and 1 indicate the length of the DCE address in semi-octets. Bits 8, 7, 6 and 5 indicate the length of the DTE address in semi-octets. Each address length indicator is binary coded and bit 1 or 5 is the low order bit of the indicator. These fields are coded with all zeros under the procedures in this Recommendation. 5.7.2.1.2 Address field Octet 5 and the following octets consist of the DCE address, when present, and the DTE address, when present. Each digit of an address is coded in a semi-octet in binary coded decimal with bit 5 or 1 being the low order bit of the digit. PAGE70 Fascicle VIII.8 - X.25 Starting from the high order digit, the address is coded in octet 5 and consecutive octets with two digits per octet. In each octet, the higher order digit is coded in bits 8, 7, 6 and 5. The address field shall be rounded up to an integral number of octets by inserting zeros in bits 4, 3, 2 and 1 of the last octet of the field when necessary. This field is not present under the procedures in this Recommendation. 5.7.2.1.3 Registration length field The octet following the address field indicates the length of the registration field in octets. The registration length indicator is binary coded and bit 1 is the low order bit of the indicator. 5.7.2.1.4 Registration field The registration field is present only when the DTE wishes to request the DCE to agree to, or to stop a previous agreement for, an optional user facility. The coding of the registration field is defined in S 7.3. The registration field contains an integral number of octets. The actual maximum length of this field depends on the network. However, this maximum does not exceed 109 octets. 5.7.2.2 Registration confirmation packet Figure 18/X.25 illustrates the format of the registration confirmation packet. Bits 8 7 6 5 4 3 2 1 Octets 1 General format identifier (see Note 1) 0 0 0 0 2 0 0 0 Fascicle VIII.2 - Rec. X.25 PAGE93 0 0 0 0 0 3 Packet type identifier 1 1 1 1 0 0 1 1 Cause Diagnostic 4 DTE address length DCE address length DCE and DTE address(es) (see Note 2) 0 0 0 PAGE70 Fascicle VIII.8 - X.25 0 0 Registration length Registration Note 1 - Coded 0001 (modulo 8) or 0010 (modulo 128). Note 2 - The figure is drawn assuming the total number of address digits present is odd. FIGURE 22/X.25 Registration confirmation packet format Fascicle VIII.2 - Rec. X.25 PAGE93 5.7.2.2.1 Cause field Octet 4 is the cause field and contains the cause of any failure in negotiation of facilities or an indication that the registration field was verified by the DCE. The coding of the cause field in the registration confirmation packet is shown in Table 23/X.25. TABLE 23/X.25 Coding of cause field in registration confirmation packet Bits 8 7 6 5 4 3 2 1 Registration/cancellation confirmed 0 1 1 1 1 1 1 1 Invalid facility request 0 0 0 0 0 0 1 1 Local procedure error PAGE70 Fascicle VIII.8 - X.25 0 0 0 1 0 0 1 1 Network congestion 0 0 0 0 0 1 0 1 5.7.2.2.2 Diagnostic code Octet 5 is the diagnostic code and contains additional information on the reason for failure of facilities negotiation. Annex E lists the coding for diagnostics. The bits of the diagnostic code are all set to 0 when negotiation is successful, or when no additional information is supplied. 5.7.2.2.3 Address length fields Octet 6 consists of the field length indicators for the DTE and DCE addresses. Bits 4, 3, 2 and 1 indicate the length of the DCE address in semi-octets. Bits 8, 7, 6 and 5 indicate the length of the DTE address in semi-octets. Each address length indicator is binary coded and bit 1 or 5 is the low order bit of the indicator. These fields are coded with all zeros under the procedures in this Recommendation. 5.7.2.2.4 Address field Octet 7 and the following octets consist of the DCE address, when present, and the DTE address, when present. Each digit of an address is coded in a semi-octet in binary coded decimal with bit 5 or 1 being the low order bit of the digit. Starting from the high order digit, the address is coded in octet 7 and consecutive octets with two digits per octet. In each octet, the higher order digit is coded in bits 8, 7, 6 and 5. The address field shall be rounded up to an integral number of octets by inserting zeros in bits 4, 3, 2 and 1 of the last octet of the field when necessary. This field is not present under the procedures in this Recommendation. 5.7.2.2.5 Registration length field The octet following the address field indicates the length of the registration field, in octets. The registration length indicator is binary coded and bit 1 is the low order bit of the indicator. 5.7.2.2.6 Registration field The registration field is used to indicate which optional user facilities are available, and which are currently in effect. The coding of the registration field is defined in S 7.3. The registration field contains an integral number of octets. The actual maximum length of this field depends on the network. However, this maximum does not exceed 109 octets. 6 Procedures for optional user facilities (packet layer) 6.1 On-line facility registration On-line facility registration is an optional user facility agreed for a period of time. This facility, if subscribed to, permits the DTE at any time to request registration of facilities, or obtain current values of facilities as understood by the DCE, by transferring across the DTE/DCE interface a registration request packet. The DCE will, in response to a registration packet, report the current value of all facilities applicable to the DTE/DCE interface, by transferring a registration confirmation packet across the DTE/DCE interface. Optional facilities which are not offered by the network will not be reported in the registration confirmation packet. To avoid requesting facilities that are not available in a particular network, or values that are not allowed, the DTE may transfer a registration request packet across the DTE/DCE interface containing no optional facilities. It may then modify any negotiable facilities reported in the corresponding registration confirmation packet by transferring a second registration request packet across the DTE/DCE interface. When the DCE returns the registration confirmation packet, the facilities values shown are in effect for any subsequent virtual calls. The values of the extended packet sequence numbering, packet retransmission, and D bit modification facilities and the allocation of logical channel type ranges can be modified only when there are no virtual calls (i.e., all logical channels used for virtual calls are in state p1). When these facilities take effect and when there is one or more logical channels assigned to permanent virtual circuits, the network restarts the interface with the cause "Registration/cancellation confirmed" and the diagnostic "No additional information" in order to change the values of the Fascicle VIII.2 - Rec. X.25 PAGE93 permanent virtual circuits at the interface. At the remote end of each permanent virtual circuit, the corresponding reset indication packet is sent with the cause "Remote DTE operational" and the diagnostic "No additional information". If a requested value of a particular facility is not allowed, the DCE shall report in the registration confirmation packet: a) if the facility has a boolean value, the value allowed; b) if the value is greater than the maximum allowed value of that facility, the maximum allowed value; or c) if the value is less than the minimum allowed value of that facility, the minimum allowed value. The registration confirmation packet shall also contain an appropriate cause code. The DTE may choose to accept the value reported by the DCE or to attempt to negotiate another value for the requested facilities. If the DCE cannot make all the modifications requested in a registration request packet, it will not alter the values of some facilities. Circumstances in which the DCE can not make all of the modifications requested include: a) conflict in facilities settings, and b) when the interface has at least one virtual call established when attempting to negotiate those facilities that require all virtual call logical channels to be in state p1 (including the collision of an incoming call packet and a registration request packet). The DTE should wait for the registration confirmation packet before sending a call request packet, or sending a packet on a permanent virtual circuit. For every optional user facility, Annex F indicates: - if the value of the facility may be negotiated; - if the registration confirmation packets indicate whether or not the facility is supported by the DCE; - if the value of the facility may be altered by the DTE either only when every logical channel used for virtual calls is in state p1, or in any packet layer state. Indication in registration confirmation packet of whether the NUI override facility is supported by the network is for further study. A fault condition within the network may affect the facilities previously negotiated by means of registration packets. In this situation, the DCE initiates the restart procedure to inform the DTE of the failure. A restart procedure initiated by the DTE does not affect the facilities values. When the DCE initiates the restart procedure with the cause "Local procedure error", the facilities values are not affected. When the DCE initiates the restart procedure with the cause "Network congestion" or "Network operational", the values of facilities previously negotiated may be affected. When the DCE initiates the restart procedure with the cause "Registration/cancellation confirmed", the facilities values are as set by the related registration procedure. 6.2 Extended packet sequence numbering Extended packet sequence numbering is an optional user facility agreed for a period of time. It is common to all logical channels at the DTE/DCE interface. This user facility, if subscribed to, provides sequence numbering of packets performed modulo 128. In the absence of this facility, the sequence numbering of packets is performed modulo 8. 6.3 D bit modification D bit modification is an optional user facility agreed for a period of time. This facility applies to all virtual calls and permanent virtual circuits at the DTE/DCE interface. This facility is only intended for use by those DTEs implemented prior to the introduction of the D bit procedure which were designed for operation on public data networks that support end-to-end P(R) significance. It allows these DTEs to continue to operate with end-to-end P(R) significance within a national network. For communication within the national network, this facility, when subscribed to: a) will change from 0 to 1 the value of bit 7 of the GFI in all call request and call accepted packets and the value of the D bit in all DTE data packets received from the DTE, and b) will set to 0 the value of bit 7 of the GFI in all incoming call and call connected packets, and the value of the D bit in all DCE data PAGE70 Fascicle VIII.8 - X.25 packets transmitted to the DTE. For international operation, conversion b) above applies and conversion a) above does not apply. Other conversion rules for international operation are for bilateral agreement between Administrations. 6.4 Packet retransmission Packet retransmission is an optional user facility agreed for a period of time. It is common to all logical channels at the DTE/DCE interface. This user facility, if subscribed to, allows a DTE to request retransmission of one or several consecutive DCE data packets from the DCE by transferring across the DTE/DCE interface a DTE reject packet specifying a logical channel number and a sequence number P(R). The value of this P(R) should be within the range from the last P(R) received by the DCE up to, but not including, the P(S) of the next DCE data packet to be transmitted by the DCE. If the P(R) is outside this range, the DCE will initiate the reset procedure with the cause "Local procedure error" and diagnostic ## 2. When receiving a DTE reject packet, the DCE initiates on the specified logical channel retransmission of the DCE data packets, the packet send sequence numbers of which are starting from P(R), where P(R) is indicated in the DTE reject packet. Until the DCE transfers across the DTE/DCE interface a DCE data packet with a packet send sequence number equal to the P(R) indicated in the DTE reject packet, the DCE will consider the receipt of another DTE reject packet as a procedure error and reset the logical channel. Additional DCE data packets pending initial transmission may follow the retransmitted packet(s). A DTE receive not ready situation indicated by the transmission of an RNR packet is cleared by the transmission of a DTE reject packet. The conditions under which the DCE ignores a DTE reject packet, or considers it as a procedure error, are those described for flow control packets (see Annex C). 6.5 Incoming calls barred Incoming calls barred is an optional user facility agreed for a period of time. This facility applies to all logical channels used at the DTE/DCE interface for virtual calls. This user facility, if subscribed to, prevents incoming virtual calls from being presented to the DTE. The DTE may originate outgoing virtual calls. Note 1 - Logical channels used for virtual calls retain their full duplex capability. Note 2 - Some Administrations may provide a capability that allows a virtual call to be presented to the DTE only in cases where the called DTE address is the address of the calling DTE. 6.6 Outgoing calls barred Outgoing calls barred is an optional user facility agreed for a period of time. This facility applies to all logical channels used at the DTE/DCE interface for virtual calls. This user facility, if subscribed to, prevents the DCE from accepting outgoing virtual calls from the DTE. The DTE may receive incoming virtual calls. Note - Logical channels used for virtual calls retain their full duplex capability. 6.7 One-way logical channel outgoing One-way logical channel outgoing is an optional user facility agreed for a period of time. This user facility, if subscribed to, restricts the logical channel use to originating outgoing virtual calls only. Note - A logical channel used for virtual calls retains its full duplex capability. The rules according to which logical channel group numbers and logical channel numbers can be assigned to one-way outgoing logical channels for virtual calls are given in Annex A. Note - If all the logical channels for virtual calls are one-way outgoing at a DTE/DCE interface, the effect is equivalent to the incoming calls barred facility (see S 6.5, particularly Note 2). 6.8 One-way logical channel incoming One-way logical channel incoming is an optional user facility agreed for a period of time. This user facility, if subscribed to, restricts the logical channel use to receiving incoming virtual calls only. Note - A logical channel used for virtual calls retains its full duplex Fascicle VIII.2 - Rec. X.25 PAGE93 capability. The rules according to which logical channel group numbers and logical channel numbers can be assigned to one-way incoming logical channels for virtual calls are given in Annex A. Note - If all the logical channels for virtual calls are one-way incoming at a DTE/DCE interface, the effect is equivalent to the outgoing calls barred facility (see S 6.6). 6.9 Non-standard default packet sizes Non-standard default packet sizes is an optional user facility agreed for a period of time. This facility, if subscribed to, provides for the selection of default packet sizes from the list of packet sizes supported by the Administration. Some networks may constrain the packet sizes to be the same for each direction of data transmission across the DTE/DCE interface. In the absence of this facility, the default packet sizes are 128 octets. Note - In this section, the term "packet sizes" refers to the maximum user data field lengths ofDCE data and DTE data packets. Values other than the default packet sizes may be negotiated for a virtual call by means of the flow control parameter negotiation facility (see S 6.12). Values other than the default packet sizes may be agreed for a period of time for each permanent virtual circuit. 6.10 Non-standard default window sizes Non-standard default window sizes is an optional user facility agreed for a period of time. This facility, if subscribed to, provides for the selection of default window sizes from the list of window sizes supported by the Administration. Some networks may constrain the default window sizes to be the same for each direction of data transmission across the DTE/DCE interface. In the absence of this facility, the default windonw sizes are 2. Values other than the default window sizes may be negotiated for a virtual call by means of the flow control parameter negotiation facility (see S 12). Values other than the default window sizes may be agreed for a period of time for each permanent virtual circuit. 6.11 Default throughput classes assignment Default throughput classes assignment is an optional user facility agreed for a period of time. This facility, if subscribed to, provides for the selection of default throughput classes from the list of throughput classes supported by the Administration. Some networks may constrain the default throughput classes to be the same for each direction of data transmission. In the absence of this facility, the default throughput classes correspond to the user class of service of the DTE (see S 7.2.2.2) but do not exceed the maximum throughput class supported by the network. The default throughput classes are the maximum throughput classes which may be associated with any virtual call at the DTE/DCE interface. Values other than the default throughput classes may be negotiated for a virtual call by means of the throughput class negotiation facility (see S 6.13). Values other than the default throughput classes may be agreed for a period of time for each permanent virtual circuit. Note - Throughput characteristics and throughput class are described in S 4.4.2. 6.12 Flow control parameter negotiation Flow control parameter negotiation is an optional user facility agreed for a period of time which can be used by a DTE for virtual calls. This facility, if subscribed to, permits negotiation on a per call basis of the flow control parameters. The flow control parameters considered are the packet and window sizes at the DTE/DCE interface for each direction of data transmission. Note - In this section, the term "packet sizes" refers to the maximum user data field lengths of DCE data and DTE data packets. In the absence of the flow control parameter negotiation facility, the flow control parameters to be used at a particular DTE/DCE interface are the default packet sizes (see S 6.9) and the default window sizes (see S 6.10). When the calling DTE has subscribed to the flow control parameter negotiation facility, it may request packet sizes and/or window sizes for both direction of data transmission (see SS 7.2.1 and 7.2.2.1). If particular window sizes are not explicitly requested in acall request packet, the DCE will assume that the default window sizes were requested for both directions of data transmission. If particular packet sizes are not explicitly requested, the DCE PAGE70 Fascicle VIII.8 - X.25 will assume that the default packet sizes were requested for both directions of data transmission. When a called DTE has subscribed to the flow control parameter negotiation facility, each incoming call packet will indicate the packet and window sizes from which DTE negotiation can start. No relationship needs to exist between the packet sizes (P) and window sizes (W) requested in the call request packet and those indicated in the incoming call packet. The called DTE may request window and packet sizes with facility in the call accepted packet. The only valid facility requests in the call accepted packet, as a function of the facility indications in the incoming call packet, are given in Table 24/X.25. If the facility request is not made in the call accepted packet, the DTE is assumed to have accepted the indicated values (regardless of the default values) for both directions of data transmission. TABLE 24/X.25 Valid facility requests in call accepted packets in response to facility indications in incoming call packets Facility indication Valid facility request W(indicated) 2 W(indicated) W(requested) 2 W(indicated) = 1 W(requested) = 1 or 2 P(indicated) 128 P(indicated) P(requested) 128 P(indicated) < 128 128 P(requested) P(indicated) When the calling DTE has subscribed to the flow control parameter negotiation facility, every call connected packet will indicate the packet and window sizes to be used at the DTE/DCE interface for the call. The only valid facility indications in the call connected packet, as a function of the facility requests in the call request packet, are given in Table 25/X.25. TABLE 25/X.25 Valid facility indications in call connected packets in response to facility requests in call request packets Facility indication Valid facility request W(requested) 2 W(requested) W(indicated) 2 W(requested) = 1 W(indicated) = 1 or 2 P(requested) 128 P(requested) P(indicated) 128 P(requested) < 128 128 P(indicated) P(requested) The network may have constraints requiring the flow control parameters used for a call to be modified before indicating them to the DTE in the incoming call packet or call connected packet; e.g., the ranges of parameter values available on various networks may differ. Window and packet sizes need not be the same at each end of a virtual call. The role of the DCE in negotiating the flow control parameters may be network dependent. 6.13 Throughput class negotiation Throughput class negotiation is an optional user facility agreed for a period of time which can be used by a DTE for virtual calls. This facility, if subscribed to, permits negotiation on a per call basis of the throughput classes. The throughput classes are considered independently for each direction of data transmission. Default values are agreed between the DTE and the Administration (see S 6.11). The default values correspond to the maximum throughput classes which may be associated with any virtual call at the DTE/DCE interface. When the calling DTE has subscribed to the throughput class negotiation facility, it may request the throughput classes of the virtual call in the call request packet for both directions of data transmission (see SS 7.2.1 and 7.2.2.2). If particular throughput classes are not explicitly requested, the DCE will assume that the default values were requested for both directions of data transmission. When a called DTE has subscribed to the throughput class negotiation facility, each incoming call packet will indicate the throughput classes from which DTE negotiation may start. These throughput classes are lower or equal to the ones selected at the calling DTE/DCE interface, either explicitly, or by default if the calling DTE has not Fascicle VIII.2 - Rec. X.25 PAGE93 subscribed to the throughput class negotiation facility or not explicitly requested throughput class values in the call request packet. These throughput classes indicated to the called DTE will also not be higher than the default throughput classes, respectively for each direction of data transmission, at the calling and the called DTE/DCE interfaces. They may be further constrained by internal limitations of the network. The called DTE may request with a facility in the call accepted packet throughput classes that should finally apply to the virtual call. The only valid throughput classes in the call accepted packet are lower than or equal to the ones (respectively) indicated in the incoming call packet. If the called DTE does not make any throughput class facility request in the call accepted packet, the throughput classes finally applying to the virtual call will be the ones indicated in the incoming call packet. If the called DTE has not subscribed to the throughput class negotiation facility, the throughput classes finally applying to the virtual call are less than or equal to the ones selected at the calling DTE/DCE interface, and less than or equal to the default values defined at the called DTE/DCE interface. When the calling DTE has subscribed to the throughput class negotiation facility, every call connected packet will indicate the throughput classes finally applying to the virtual call. When neither the calling DTE nor the called DTE has subscribed to the throughput class negotiation facility, the throughput classes applying to the virtual call will not be higher than the ones agreed as defaults at the calling and called DTE/DCE interfaces. They may be further constrained to lower values by the network, e.g., for international service. Note 1 - Since both throughput class negotiation and flow control parameter negotiation (see S 6.12) facilities can be applied to a single call, the achievable throughput will depend on how users manipulate the D bit. Note 2 - Users are cautioned that the choice of too small a window and packet size of a DTE/DCE interface (made by use of the flow control parameter negotiation facility may adversely affect the attainable throughput class of a virtual call. This is likewise true of flow control mechanisms adopted by the DTE to control data transmission from the DCE. 6.14 Closed user group related facilities A set of closed user group (CUG) optional user facilities enables users to form groups of DTEs to and/or from which access is restricted. Different combinations of access restrictions to and/or from DTEs having one or more of these facilities result in various combinations of accessibility. A DTE may belong to one or more CUGs. Each DTE belonging to at least one CUG has either the closed user group facility (see S 6.14.1) or one or both of the closed user group with outgoing access and the closed user group with incoming access facilities (see SS 6.14.2 and 6.14.3). For each CUG to which a DTE belongs, either none of the incoming calls barred within a closed user group or the outgoing calls barred within a closed user group facilities (see SS 6.14.4 and 6.14.5) may apply for that DTE. Different combinations of CUG facilities may apply for different DTEs belonging to the same CUG. When a DTE belonging to one or more CUGs places a virtual call, the DTE may explicitly indicate in the call request packet the CUG selected by using the closed user group selection facility (see S 6.14.6) or the closed user group with outgoing access selection facility (see S 6.14.7) (see Note). When a DTE belonging to one or more CUGs receives a virtual call, the CUG selected may be explicitly indicated in the incoming call packet through the use of the closed user group selection facility or the closed user group with outgoing access selection facility. Note - For a given virtual call, only one of the above-mentioned selection facilities can be present. The number of CUGs to which a DTE can belong is network dependent. 6.14.1 Closed user group Closed user group is an optional user facility agreed for a period of time for virtual calls. This user facility, if subscribed to, enables the DTE to belong to one or more closed user groups. A closed user group permits the DTEs belonging to the group to communicate with each other but precludes communication with all other DTEs. When the DTE belongs to more than one closed user group, a preferential closed user group must be specified. PAGE70 Fascicle VIII.8 - X.25